home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 17087 < prev    next >
Encoding:
Text File  |  1996-08-05  |  3.5 KB  |  90 lines
  1. Newsgroups: comp.lang.java,comp.lang.c++,comp.lang.smalltalk
  2. Path: in2.uu.net!allegra!alice!ark
  3. From: ark@research.att.com (Andrew Koenig)
  4. Subject: Re: Will Java kill C++?
  5. Message-ID: <Dpt0FD.Et4@research.att.com>
  6. Organization: AT&T Research, Murray Hill NJ
  7. References: <31683229.446B9B3D@bbn.com> <DpJs8I.8tn@research.att.com> <4kn3c4$1ggc@piglet.cc.uic.edu>
  8. Date: Sat, 13 Apr 1996 14:04:24 GMT
  9.  
  10. In article <4kn3c4$1ggc@piglet.cc.uic.edu> dhanle2@icarus.cc.uic.edu (David James Hanley) writes:
  11. > andrek koenig wrote:
  12.  
  13. Is your transformation of my name supposed to be clever?
  14. To make you feel like a better, more noble person?
  15. To make your arguments more intellectually compelling?
  16. To show the world that you enjoy insulting strangers?
  17.  
  18. > : In article <31683229.446B9B3D@bbn.com> Joe Kraska <jkraska@bbn.com> writes:
  19.  
  20. > : > ANSI-C libraries are much easier to handle than C++ 
  21. > : > libraries, for a whole host of reasons, not the least of which is
  22. > : > the stupid-dumb-fuck-mistake of not having a name-mangling standard
  23. > : > for C++.
  24.  
  25. > : The thing about hurling expletives around like that
  26. > : is that it's so embarrassing when you're wrong -- as
  27. > : you are in this case.
  28.  
  29. >     Or that he is correct, as he is in this case.
  30.  
  31. Correct about what?  That having a name-mangling standard for C++
  32. would make C++ libraries easier to handle.  Sorry, but he's wrong,
  33. and so are you.
  34.  
  35. Name mangling, that is, the conventions that a compiler uses
  36. in translating names from the source program into names
  37. that the linker sees, is only one of a large number of things
  38. that must be agreed before programs compiled with one compiler
  39. can be linked with programs compiled with another.  If some
  40. of those things are made compatible and not others, that can
  41. easily make the problems worse instead of better.  The reason
  42. is that programs may appear to work compatibly when in fact
  43. they are working only by accident.
  44.  
  45. > : Having a name-mangling standard would not solve any
  46. > : problems, because it would do nothing toward solving
  47. > : the binary compatibility problems that affect not
  48. > : only C++ but also C.
  49.  
  50. >     Really?  I'll have to remember that next time I like a gnu C
  51. > compiled program with a sun c compiled program.  
  52.  
  53. > : I have two mutually incompatible C compilers on my workstation.
  54. > : They generate names that look the same to the linker, but they
  55. > : put arguments and return results in different registers.
  56.  
  57. >     That's too bad.  All of mine link ok.
  58.  
  59. Well, good for you.  That still does not gainsay the fact that
  60. handing the same names to the linker does not make compilers
  61. compatible.
  62.  
  63. > : Getting a single binary library to work with both those
  64. > : C compilers is no easier than it is in C++.
  65.  
  66. >     Wrong.  As evidence, we do this all the time in C,
  67. > but I've never seen it done in C++. 
  68.  
  69. I completely agree with you that link compatibility between C++
  70. compilers is more difficult to achieve, hence less common, than
  71. link compatibility between C compilers.
  72.  
  73. But agreeing on a standard for name mangling would not solve that
  74. problem, because it is vanishingly rare that two C++ compilers are
  75. binary compatible in all details except for names.
  76.  
  77. > :  In fact, I can
  78. > : plausibly argue that it would be easier if those two compilers
  79. > : used different conventions for linkage names -- that way I could
  80. > : tell when I was headed for a fall before trying to run the
  81. > : program.
  82.  
  83. >     I see.  Running the program once during the development cycle would
  84. > be too much effort.
  85.  
  86. More to the point, it wouldn't prove anything if it appeared to work.
  87. -- 
  88.                 --Andrew Koenig
  89.                   ark@research.att.com
  90.